instead of silently doing nothing for side modules, how about Fatal() << "stack overflow checks are not supported with side modules"; ?

Well, we actually need to do nothing for side modules because all stack operations gets turned into stackSave and stackRestore, which are exported from the main module. In the main module, stackRestore performs the overflow check.

Is that right? I thought side modules manage their own stack in their own memory. At least that's how fastcomp does it - is it completely different in the wasm backend?

Seems like it. This is the prologue of a function in the side module:

 (func $f (; 5 ;) (type $2) (result i32)
  (local $0 i32)
  (local $1 i32)
  (local $2 i32)
  ...
  (local.set $0
   (call $stackSave)
  )
  (local.set $1
   (i32.const 8192)
  )
  (local.set $2
   (i32.sub
    (local.get $0)
    (local.get $1)
   )
  )
  (call $stackRestore
   (local.get $2)
  )

and this is the epilogue:

  (local.set $7
   (i32.const 8192)
  )
  (local.set $8
   (i32.add
    (local.get $2)
    (local.get $7)
   )
  )
  (call $stackRestore
   (local.get $8)
  )

stackSave and stackRestore are imported:

 (import "env" "stackSave" (func $stackSave (result i32)))
 (import "env" "stackRestore" (func $stackRestore (param i32)))

That's very surprising. Let's see what @sbc100 says. But that doesn't need to block this PR landing (we may need a followup though).

Why is this surprising? The sp with the wasm backend is mutable global but we don't have any way to import or export mutable globals (yet), so the side module has to manipulate the global via these helper functions.

I see, thanks @sbc100

I guess I'm used to the fastcomp model where not just threads but shared modules also got their own stack.